Wow, so that pretty clearly points the finger DIRECTLY at some cache Adobe controls (unless this was helped by some other amazingly coincidental change they did not perform).   If it's the former, then we not only want to cry out for them to "fix this" in a way that better resolves it going forward, but they should implement some sort of check that runs (perhaps from multiple worldwide locations), which confirms that it gets whatever is expected foe the current update--and for EACH of the files updated and downloaded by the update process.   Can you ask this of whoever you're interacting with?  ... View more

Did you happen to try just installing that feed package, vs an entire manual install of the update?   Beyond that, I have a few more suggestions related to @a_1001 's observation.    To be clear, all 3 of this week's updates DO indicate that the feed package (alone) is to updated. (As for whether it IS updated is another question. I found on one of the versions it was not.)    But you're saying it was/remained REMOVED after the update. I've not seen that yet among the dozen updates I've done this week.   Note that when a package IS to be updated, it is in fact first REMOVED--as tracked during the startup of cf, in the coldfusion-out.log. But while it does NOT show it being "installed" or even "updated" in that log: it only shows installed ones being "started".    I suspect you'll find in the log that after the feed package was uninstalled, there was another message (perhaps a dozen or more lines later) indicating whatever specifically happened.   That's not new to this update (that such a package update failed can happen, and that it's logged, which could explain WHY it happened and might suggest a solution).   I just saying it might help you and others to explore a bit further. But perhaps you've already proceeded with the manual cf update--or maybe just installing the package will suffice.   I do appreciate your sharing the observed problem. I'm just trying to help with possible diagnosis and resolution. I cover that a bit more in my blog post about the update (much of which applies to any cf update).  ... View more

And thank you for the kind regards. Again, some find that to be true--and there are a couple of situations where it's the best option--certainly an offline manual update, or also when the user for the cf service is not the system account (on windows) or root (on Linux) and so can't cause stop/start of the cf service to do the cf update.   But your issue seems to be about packages, and I'll just say I've not yet once had to do a manual update to solve that sort of problem. Not negating your experience, just sharing mine--that it's always better or necessary to do a manual (java -jar) update. ... View more

Sadly, you could be howling at the wind here. The troubles happen to many (but again, not everyone), and those who suffer can certainly commiserate here--but there's no assurance Adobe will hear your complaint here.   Better to file a bug report at tracker.adobe.com (I suspect many have, about such update issues), or complain directly to cfsup@adobe.com (perhaps only to be told "the developers are investigating" this problem... though they DO fix many.)   Indeed, I'll note that Adobe DID say after the last update that the problem related to mail (the one fixed by clearing the felix-cache) was to be fixed in the "next" update. Since THIS one was an urgent security fix, no bug fixes were included. Perhaps the NEXT one will improve things.   If things don't improve with these various update issues, I'm sure some may well vote with their feet.   Until then (or otherwise), I and others (including some from Adobe) are here to try to help.  ... View more

Did you try clearing the felix-cache? Though not indicated for this update, it was often needed to solve mail problems in the previous one--which suggested that after the update, one should stop cf, delete the cfusion/bin/felix-cache folder, then restart cf, which would recreate the folder and what goes in it. (And if you're running multiple instances, delete [instancename]/bin/felix-cache. )   I realize this suggestion may be too late for you if you've uninstalled the update. I leave it then for others.  ... View more

Thanks for the update--and for pressing the point with them.   Would be nice if they'd setup some periodic monitor, to check. Beyond any logged in user not seeing their own bugs reported or ones they voted on, while the problem happened even visiting an existing bug reported it was not there. That's how they could easily monitor without need of a login (which can be more challenging). ... View more

Critic, I'll confirm I saw that also--on one cf2025 machine (only one, among a few cf2025 updates I've done since yesterday).   FWIW, I found that the files in question were identified first as missing in errors shown during the cf startup (after the update) in the coldfusion-out.log. Then I also saw them listed as files REMOVED by the update itself, as tracked in the hotfixfilelist.log, found in the hf-updates folder for that cf update. These removed files matched those listed as missing in the startup.   And like you, I "put them back" in the cf bundles/repo, as they were saved during the update in the hf-updates folder for the update, in its backup/bundles folder. Then the restart showed no errors in the coldfusion-out.log.    It's not clear to me now why this would have happened on that one server and not the other cf2025 (nor cf2023 or cf2021) instances I updated, when they all were installed with the same (Windows) installer, each having all packages implemented, and each updated when a new update came out.   Just sharing those distinctives, if it may help others looking into it. Until then, hope the steps I offer may help someone.  ... View more

It's certainly interesting to hear you're both in the UK. I was tempted to ask originally. Will be very interesting if that clue helps anyone identify the root cause problem.   In the meantime, would any of you be in a position to change the cf update proxy settings to use a VPN the routes your traffic through a US server? (Should you have to? No. Neither should people have to suffer the pain of some medical treatments: but we weigh that against the disease.)   To be clear, the cf admin package manager page has a "settings" tab at the top, which offers this proxy option.   Or let's see what other news shakes out.  ... View more

@w49369461 that url is indeed "working" for many and showing references to yesterday's update within the xml itn returns. As I noted just now in a reply to a_1001, some people seem to experience a lag in the updated content appearing to them, for whatever reason (web caches, cdn's, etc) . The complaints about it usually passes within a day of the update.    Have you tried the url from your phone or home? Does it have a reference to "- 022", for instance, which is part of the string describing update 22 of cf2021?   If so, you could then follow the steps to "Install the update in offline mode manually" as outlined in each update's technote. In this case you'd download the needed files (whose links are offered in the technote) onto that other machine , then copy them to the CF machine to be updated. Not fun, I realize. Or wait to see if the web caching issues clear for you.  ... View more

@a_1001 it's appeared on the dozen machines I've updated since yesterday afternoon (on multiple networks, between my own machines and those of some clients who've asked me to do the updates for them already) . As always, there seems to be some lag on caching issue that SOME experience, but it's not at all universal nor the majority. It usually passes within a day or two.   See more I'll have to say to w49369461 below.  ... View more

Chuck, 2 things.   1) First, uep, as for your "inconsistencies" about accessing the URLs (or what's returned from them), that's a common problem for some (not everyone) in the first hours or even day after these updates are released. I assume Adobe is using some CDN, yes, or some other sort of caching within their large enterprise architecture. Sadly, some may be out of our hands (and the CF teams's.   I do find it odd that some have the problems and others don't--which makes me think it's more NOT about Adobe's server's or architecture, per se. But who can know? 🙂   2) Also yes: the feed package was updated for CF2023.   And it may help to know that Adobe does in fact offer a table at the bottom of each update technote which lists what packages are due to be updated along with the core update, for each update. (And another after that listing whether the web server connector needed to be updated, per each update.)   Of course, if one SKIPs any updates, then you get updates to whatever packages are listed below that as well, for the updates you skipped.   Better still, one could look in the CF Admin to see what packages it may list as "to be updated". Of course, some may not pay notice it--and others run the update from the commandline, not even seeing the Admin.   For either of them, one can look to the update log (created for each update, within the cfusion/hf-updates folder for the update applied). As some may know, that shows first (at about line 70) how many "successes" and "fatalerrors" happened in the update. And THEN it also lists (several lines up from the bottom) what packages (if any) were downloaded (to be updated). And as some may know, those are then updated NOT at THAT time (during the CF update) but on the next start of CF AFTER the update. And one can see in the coldfusion-out.log that during that next startup, it will show first "uninstalling" packages and associated jars, but it won't show "installing" them. It will just show them being "started".   Each of those are useful to watch after each update.  🙂 ... View more

wt, I did understand that your focus was the zip. That's why I'd offered the link to that. Glad all is working for you now. (My reference to the JAR was for Saurav's sake, to correct as it was indeed just a bad href url.)   But yes, it can be that caching anywhere along the line (between your CF instance/testing browser and the Adobe server) could have been stale or incorrect and then corrected. Something folks should consider when they want to "jump on an update" as soon as it comes out. 🙂 ... View more

@wtlaughlin , I am not finding the link to that update jar to fail. I can offer the working link, and then below that I report a problem of a link that IS incorrect in another page about cf2023's update 16.   1) As you may have noticed, the link you show is missing a domain name. Have you tried it as the full URL, https://cfdownload.adobe.com/pub/adobe/coldfusion/2021/packages/hotfix-packages-cf2021-022-330451.zip? That works for me. If it works, great. As for where you found the bad link, I'll note that I don't see that shortened version (without the domain name) in any of the pages offering that download (which would be either the CF2021 update 22 technote or the page listing all the cf2021 updates (and those links for each). Can you say where you found it?   2) Then again, as a note to Saurav (who handles the docs) and other readers here: note that I DO find a mistaken link in the page of cf2023 updates for the CF2023 update 16 jar.  It offers the link as https://cfdownload.adobe.com/pub/adobe/coldfusion/2023/updates/hotfix-015-330828.jar , but see the mistake: it refers to 015 rather than 016—but the numbers following it are correct for the build number, so just changing that 15 to 16 works: https://cfdownload.adobe.com/pub/adobe/coldfusion/2023/updates/hotfix-016-330828.jar     I confirmed that the links to the jar and zip as offered in the 3 release update technotes are correct, as are all the other links for today's updates in the pages that list all the updates for each release, with their file download links (but this one problem in my point 2 above).   It's a lot for Saurav to juggle, of course. As always, just trying to help (him and other readers). ... View more

You're not alone, Mike. I've experienced the past couple of days, and on and off over recent weeks. Glad to hear you emailed them. Let's hope they address it.   BTW, I tweaked tour original post to turn your reference into a link--for those who may not know the url or just to make it easier for folks just to click on it. 🙂 To be clear, I very rarely edit folks' posts. In this case I hoped you'd have no reason to object to the slight tweak, and I didn't want to leave you wondering about the change. 🙂  ... View more

Very glad to hear you found it helpful. And I see that bkbk marked it as an "answer". Thanks.  We'll see if any new info may be shared over time, whether from Adobe or others.  ... View more

Bkbk, I realize you're insistent that your xml is "working". My experience is that it's not. But I've be saying from the outset: let's not debate it with words.   Just prove it for yourself: change your jetty-inetaccess.xml to name in its whitelist only one ipv4 and ipv6 address that DOESN'T exist. Don't worry about the blacklist for now. Then in your start.ini, comment out the ipaccess module (so it's not in play, since @iclark3509 's goal was to block ipv6, which that module can't do.)    Now restart your add on service, and do your url test. Does it fail? It should, if your jetty-inetaccess.xml is working, but you only whitelist non-existent ip address as the caller.   If it does not fail, check what ip address is reported in that first column of the jetty request log. If it gets a 200 the clearly the whitelist (which should only allow what you name) IS NOT working.   And if that's not proof enough, NOW add that ip address to the black list (whatever one was reported in the log for your working test request). The restart the add on service and test again. Does it NOW block your request?   It doesn't for me, for your xml. It does for me, for my version I offered--as long as enable the inetaccess module. Finally, if I put your xml in instead (with that module enabled), then jetty won't start.   Does that make sense for you? Will you please take a few mins to test things, as I'd done for yours? Then you can test if mine DOES so the job (allowing control by ipv6 addresses). .   Again, I'm not here to win points or win arguments. I'm trying to help you and Ian and other readers, who may want to leverage the jetty-inetaccess.xml to whitelist or blacklist ipv6 addresses.   So far you and I seem to be about the only people IN THE WORLD considering this matter. (We're not even hearing from Ian since his original post.) You can help advance the knowledge base by offering just this few more minutes of your time.  ... View more

Keep digging.  ... View more

Let's see what you find.    And no, it is NOT at all that I "took the idea and ran with it in different directions". Before you wrote your first note with an offered jetty-inetaccess.xml file, I'd already SAID I had a working solution. It was taking me a long time to write about it (which is now clear why, if you read it).   Your jetty-inetaccess.xml FAILED TO LOAD when the inetAccess module was correctly implemented. Hopefully your testing will show that.   I had already acknowledged (twice) that the other jetty-http.xml change could help Ian a different way. I also tried to explain why.   Finally, my mention of blacklisting was merely as a way he or you or anyone in the future could confirm if the jetty-inetaccess.xml file was working at all (since most could not easily change what ipv6 address their request would come FROM.)   Again, I'm trying to help here. So like I said, let's see what your next steps find.  ... View more

FWIW, I've found that file protocol to NOT be necessary, and a simple file path alone did suffice.   I'd be curious to hear of either of you (or Adobe or any other reader) might confirm that. It would seem helpful not to have to suggest that file:// protocol as always required.  ... View more

Well, actually, the update technotes DO tell you to do what you did. So it SHOULD work.   Other resources suggest the shortcut you're now proposing. Something never clear with those is whether one should be merely copying into the cfusion/bundles or REPLACING what's there (which means removing from there what's NOT in the zip). That may be important.   But I get it that you're resolved. My focus was on why you experienced what you did--and why that documented approach would not work for you.  ... View more

Fair enough. Let's see how things go with you and Adobe support. (If somehow things aren't resolved, I offer remote screenshare consulting and fix many problems in as little as 15 mins billable time--and you won't pay for time you don't find valuable. More at carehart.org/consulting.)   Hopefully you guys will resolve it. Looking forward to your sharing the conclusion.  ... View more

Your logs don't disprove what I said. Why must it always be this way between us? Dude, I gave you the specific steps to show why what you offered in your jetty-inetaccess.xml is NOT the solution AND IS NOT WORKING, at least with respect to the problem of supporting requests FROM an ipv6 address.   Again, try blacklisting that ipv6 address (shown in your log) using your xml. Is it blocked? Until you do that, your offered xml is more confusing to matters than helpful.   I tried to be very clear and helpful in my reply to you. I explained why your jetty-http.xml alone was allowing what you're seeing. (But that's NOT proving the ipb6 whitelist/blacklist you propose is working.)   And I feared that despite my best efforts there, you'd only see red at my temerity to question you. Read it again, or don't. I'm done with this, regarding your proposed jetty-inetaccess.xml solution. Hell, you even posted your reply after my very long response with the working jetty-inetaccess.xml (including proof that it's working), but you make no reference or comment on it here.    I just hope discerning readers carefully consider all that's been said.  ... View more

Ok, Himanshu. But your first question here said you were having trouble calling the rest services with other than port 8500. THAT problem is solved by using the wsconfigproxy tool (and also configuring cf to expect it, as discussed in the resources I linked to).   Now you're saying (also?) that you had problems with cfm pages. And fair enough that you've solved it with the wsconfig tool. That would seem unrelated to requesting cf REST services via iis.   Though let me add that if one sets up cf pages (cfm or cfc) to be "used for REST" without actually using the CF REST feature (introduced in cf11, and again discussed in the resources I linked to), then that is indeed NOT relying on the wsconfigproxy and cf admin ws proxy settings.   Anyway, it seems your problem is solved, which is great. I just leave this as context for future readers.  ... View more

Thanks for pointing out that distinction. I'd missed it (bringing phone, long lines are spread over many, which can hide such pattern differences).   So as for the oddity, let's look at it differently. I see you say regarding the zip file that you "unzipped it to directory /appl/CF2023-15-installer/bundles/". And fair enough. Then you pointed the packagesurl at that unzipped result as /appl/CF2023-15-installer/bundles/bundlesdependency.json. Again, fair enough. And then you got the confusing message.   Here's a thought: let's have you make sure that json file you named is indeed there. Again, as you're on Linux: cat /appl/CF2023-15-installer/bundles/bundlesdependency.json Does that indeed show the json expected? As important, is the file indeed there? Folks use different unzip tools and arguments, and it could have been that you didn't end up with that at that place in the path provided.   And I wonder (if that's the issue) whether cf then tried looking elsewhere, thus the error you saw.   Let us know what you find, and I hope you'll do this even while awaiting Adobe's help, just to xlose out the question I've raised (which could help others, in a similar predicament).  ... View more

Great to hear...but did you run the wsconfig tool, or the wsconfigproxy tool? And in saying re-ran it, what differed this time?   Asking on behalf of other readers who may find this thread.  ... View more

Well, when you do the successful createobject call, do you name the cfc as being in the same path you use in the jq call, shared/cf/excel?   It's when the cfc is called (or a cfm) that Cf looks for an application.cfc (or cfm) in the directory holding that, or it's parent, andnso on until one is found.   Ecdn if you think all's correct, since things don't work you need some diagnostics. Use the cf function getapplicationmetadata() to return what properties were (or were not) set per the application.cfc/cfm found by cf when calling that cfc. You could dump it to a file, since your jq call probably expects json or xml rather than the html is dump would output by default. Note that cfdump/writedump has flexibility to send its output to a file, as html or not.   Let us know what you find.  ... View more

Yes, look up the cf docs (not the cfml reference) on using the CF REST service, and in particular the wsproxyconfig tool, which allows you to connect to such cf rest services via iis (or apache), rather than that port 8500 which is cf's web server.   Among the docs and other resources on this (introduced with cf11 in 2014) are:   https://helpx.adobe.com/coldfusion/developing-applications/coldfusion-and-html-5/using-coldfusion-websocket/websocket-enhancements.html https://learn.xbytecloud.com/t/how-to-enabled-coldfusion-websockets-with-iis/130   Let us know how it goes.  ... View more

Well, that was in fact a problem a few years ago, when updates to Java 8 and 11 stopped supporting an old tls version, so that calls form cf (from Java) to such servers now failed.    But your on java 17, which came out after that.    Even so, tell us first what you see as the error when you dump the cfhttp struct after the cfhttp. It would be preferable to offer the text of the error (not just a screenshot as you did before), in case we may need to look it up.   In the meantime, you may want to look at what I shared in my post back then, as you may see some things to consider related generally to your current issue.  ... View more